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Remarks 

Applicants respectfully request reconsideration of the present application in view of the 
foregoing amendments and the following remarks. Claims 1, 21, 28, and 35 are independent. 
Claims 36-40 are new. 

Claim Rejections 35 USC $ 102 

The Action rejects claims 1-9 and 21-35 under 35 U.S.C. 102(b) as being unpatentable by 
De Armas, U.S. Patent 5,864,819 (De Armas). For a 102(b) rejection to be proper, the applied 
art must show each and every element as set forth in a claim. (See MPEP § 213 1 .01). 
Applicants respectfully traverse. 

Claim 1. 

Applicants respectfully submit that the art cited by the Office fails to teach or suggest the 
claim 1 arrangement "in response to receiving the data indicative of the user interface element of 
interest, generating an element path identifier of the user interface element of interest for 
persistently and uniquely identifying the user interface element of interest and returning at least 
the unique element path identifier to the first software component; wherein persistently and 
uniquely identifying the user element of interest comprises persistently and uniquely identifying 
the user interface element of interest across reboots of the computer running the source 
computer program. " These features are discussed in the application, for example, at page 2 line 
25 to page 3, line 2, and page 7, lines 12-25. 

Applicants have further amended the claim to point out "wherein persistently uniquely 
identifying the user element of interest comprises persistently uniquely identifying the user 
interface element of interest across reboots of the source computer program." The Application 
gives an overview: 

Described herein are Application Programming Interfaces that enable client 
applications to request and receive identifiers for user interface elements in a 
graphical user interface of a computer program, wherein the identifiers are 
capable of persistently identifying the user interface elements across different 
instances of the computer program, across different builds of the program, across 
reboots of the computer running the computer program etc. A persistent identifier 
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is one that is not fragile and maintains its identity across events such those 
mentioned above. 

[Application, page 2, line 25 to page 3, line 2.] 

Applicants respectfully submit that the system of De Armas which relies on instance 

specific window handles to uniquely identify a window fails to anticipate the recited 

arrangement. [See De Armas, 9:43-50.] A window handle is "a dynamic, instance specific, 

operating system identification number." [De Armas, 9:43-74.] As each window handle is 

instance specific, they will change between reboots of a computer program. 

This is explained in more detail by De Armas, below. 

It should be noted that the window handle is an essential piece of 
information which is necessary to allow the associated window object to be 
uniquely identified by the operating system. The window handle is a dynamic, 
instance specific, operating system identification number, which permits a 
window object to be uniquely identified within the operating system at any given 
moment in the execution of the target application. [De Armas, 9:43-50, emphasis 
added.] 

De Armas specifically notes that window handles are "an essential piece of information" 
necessary for unique identification of a window object. [Id.] The window handles are also 
"dynamic" and "instance specific." [Id.] A reboot requires, at a minimum, that the computer 
program be recompiled; thus also requiring a new program instance. The new computer program 
instance will have all new window handles, as the handles are "instance specific." As such, 
these instance-specific window handles used in the identification of window objects will not 
survive a reboot, and so cannot be used to uniquely identify a user interface element across a 
reboot. 

Thus, as the essential window handles of De Armas cannot be used to at least partially 
identify a user element of interest across reboots of the source computer program, De Armas 
cannot anticipate, and teaches away from e.g., the claim 1 language "wherein persistently and 
uniquely identifying the user element of interest comprises persistently and uniquely identifying 
the user interface element of interest across reboots of the source computer program." 

As De Armas not only does not anticipate the claim features, above, but instead actively 
teaches away from them, Applicants respectfully state that claim 1 is in condition for allowance. 

Accordingly, favorable reconsideration and withdrawal of the rejection of independent 
claim 1 under 35 U.S.C. §102 is respectfully requested. 



Page 9 of 12 



GL:kam 02/01/08 845625 306082.01 
PATENT 



Attorney Reference Number 3382-66149-01 
Application Number 10/692,923 



Claims 2-9. 

Each of claims 2-9 depends directly or indirectly from claim 1 . Applicants will not 
belabor the merits of the separate patentability of claims 2-9, except to say that as they ultimately 
depend from an allowable claim, they should be also be allowable, for at least that reason. 
Claims 2-9 also are separately patentable. Claims 2-9 should be allowable. Such action is 
respectfully requested. 

Claims 21, 28, and 35. 

Amended claim 21 recites "such that the output parameter represents an identifier capable 
of persistently identifying the user interface element of interest across different builds of the 
computer program." 

Amended claim 28 recites "such that the output parameter represents an identifier capable 
of persistently identifying the target user interface element across different builds of the 
computer program.'" 

Amended claim 35 recites "such that the element path identifiers persistently identify the 
user interface elements across a build of the computer program." 

De Armas fails to anticipate, at least, the recited arrangements, above. 

The system of De Armas explicitly relies on window handles to uniquely identify 

different windows. [See De Armas, 9:43-50.] A window handle is "a dynamic, instance 

specific, operating system identification number." [De Armas, 9:43-74.] As window handles are 

instance specific, they will not survive a build of a computer program, and thus cannot be used to 

identify a user interface element across different builds of a computer program, as after each 

build, the window handles change. 

This is explained in more detail by De Armas, below. 

It should be noted that the window handle is an essential piece of 
information which is necessary to allow the associated window object to be 
uniquely identified by the operating system. The window handle is a dynamic, 
instance specific, operating system identification number, which permits a 
window object to be uniquely identified within the operating system at any given 
moment in the execution of the target application. [De Armas, 9:43-50, emphasis 
added.] 
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De Armas specifically notes that window handles are "an essential piece of information" 
necessary for unique identification of a window object. [Id.] The window handles are also 
"dynamic" and "instance specific." A computer program build requires, at a minimum, that the 
computer program be recompiled; thus also requiring a new application instance. The new 
computer program instance will have all new window handles, as the handles are "instance 
specific." As such, these instance-specific window handles used in the identification of window 
objects will not survive a build, and so cannot be used to uniquely identify a user interface 
element across different builds. 

Thus, as the essential window handles of De Armas cannot be used to at least partially 
identify a user element of interest across builds of the computer program, De Armas cannot 
anticipate, and teaches away from persistently identifying user interface elements across another 
build of the computer program, and thus teaches away from, e.g., amended claim 21 language 
"such that the output parameter represents an identifier capable of persistently identifying the 
user interface element of interest across different builds of the computer program" amended 
claim 28 language "such that the output parameter represents an identifier capable of persistently 
identifying the target user interface element across different builds of the computer program? 
and amended claim 35 language "such that the element path identifiers persistently identify the 
user interface elements across a build of the computer program^ . 

As De Armas not only does not anticipate the claim features, above, but instead actively 
teaches away from them, Applicants respectfully state that claims 21, 28, and 35 are in condition 
for allowance. 

Accordingly, favorable reconsideration and withdrawal of the rejection of independent 
claims 21, 28, and 35 under 35 U.S.C. §102 are respectfully requested. 

Claims 22-27, and 29- 34. 

Each of claims 22-27, and 29-34 depends directly or indirectly from claims 21 and 28. 
Applicants will not belabor the merits of the separate patentability of claims 22-27, and 29-34, 
except to say that as they ultimately depend from an allowable claim, they should be also be 
allowable, for at least that reason. Claims22-27, and 29-34 are also separately patentable. 
Claims 22-27, and 29-34 should be allowable. Such action is respectfully requested. 
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Support for Amendments and New Claims 

Support for the Amendments and new claims is found throughout the Specification and 
Figures as initially filed. In addition, the following examples of support are given: 
The specification, page 2, line 25 to page 3, line 2; and page 6 line 18 to page 7, line 25. 



If any issues remain, the Examiner is formally requested to contact the undersigned 
attorney prior to issuance of the next Office action in order to arrange a telephonic interview. It is 
believed that a brief discussion of the merits of the present application may expedite prosecution. 
Applicants submit the foregoing formal Amendment so that the Examiner may fully evaluate 
Applicants' position, thereby enabling the interview to be more focused. 

This request is being submitted under MPEP § 713.01, which indicates that an interview 
may be arranged in advance by a written request. 



Request for Interview 



Conclusion 



The claims should be allowable. Such action is respectfully requested. 



Respectfully submitted, 



KLARQUIST SPARKMAN, LLP 



One World Trade Center, Suite 1600 
121 S.W. Salmon Street 
Portland, Oregon 97204 
Telephone: (503) 595-5300 
Facsimile: (503)595-5301 



By 



Genie Lyons 
Registration No. 43,841 



/Genie Lyons/ 
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